Skip to content

Perf/bound review latency - #803

Open
MingsingGo wants to merge 4 commits into
alibaba:mainfrom
MingsingGo:perf/bound-review-latency
Open

Perf/bound review latency#803
MingsingGo wants to merge 4 commits into
alibaba:mainfrom
MingsingGo:perf/bound-review-latency

Conversation

@MingsingGo

Copy link
Copy Markdown

Description

Type of Change

  • Bug fix (non-breaking change that fixes an issue)
  • New feature (non-breaking change that adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Refactoring (no functional changes)
  • Documentation update
  • CI / Build / Tooling

How Has This Been Tested?

  • make test passes locally
  • Manual testing (describe below)

Checklist

  • My code follows the project's coding style (go fmt, go vet)
  • I have performed a self-review of my code
  • I have added tests that prove my fix is effective or my feature works
  • New and existing unit tests pass locally with my changes
  • I have updated the documentation accordingly (if applicable)
  • I have signed the CLA

Related Issues

@CLAassistant

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

@github-actions

github-actions Bot commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

🔍 OpenCodeReview found 2 issue(s) in this PR.

  • ✅ Successfully posted inline: 2 comment(s)

Comment thread cmd/opencodereview/review_cmd.go Outdated
Comment on lines +103 to +105
if opts.maxTokens > 0 {
cc.Template.MaxTokens = opts.maxTokens
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[bug · high]
Bug: When maxTools is 0 (the default), the template's MaxToolRequestTimes is never overridden. However, the template validation in loadCommonContext checks if t.MaxToolRequestTimes <= 0 and returns an error. If the embedded template has MaxToolRequestTimes = 0, this will fail validation even though the user didn't explicitly set the flag. The old logic (if maxTools > tpl.MaxToolRequestTimes) would only override when the user explicitly set a higher value, preserving the template's default. The new logic breaks this by treating 0 as "use template default" but the template might have 0, causing validation to fail.

Comment on lines +56 to 58
if maxTools > 0 {
tpl.MaxToolRequestTimes = maxTools
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[bug · high]
Bug: Scan command behavior changed. The change from maxTools > tpl.MaxToolRequestTimes to maxTools > 0 breaks the scan command's documented behavior.

In scan_cmd.go:111, the scan command still uses the old "only raise" logic:

if opts.maxTools > scanTpl.MaxToolRequestTimes {
    scanTpl.MaxToolRequestTimes = opts.maxTools
}

But now loadCommonContext will override the review template's MaxToolRequestTimes whenever maxTools > 0, even if it's lower than the template default. This contradicts the scan flag's help text at line 177: "max tool call rounds per file; only takes effect when greater than template default".

The review command should also only raise the limit, not lower it, to match user expectations and the documented behavior.

Suggestion:

Suggested change
if maxTools > 0 {
tpl.MaxToolRequestTimes = maxTools
}
if maxTools > tpl.MaxToolRequestTimes {
tpl.MaxToolRequestTimes = maxTools
}

…d-review-latency

# Conflicts:
#	cmd/opencodereview/shared_flags.go
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants